feat: webMCP registers the editor's manifest tools on the host page - #47

Background

An in-browser agent (ChatGPT's browser, Chrome with WebMCP) discovers tools on the page it is looking at, not inside iframes. The SimplePDF editor registers its operations as WebMCP tools on its own page, so a site that embeds the editor exposes nothing to the agent. This PR lifts the editor's tools to the host page: webMCP registers, on the embedder's document.modelContext, the very records the editor publishes in its manifest (https://simplepdf.com/embed/json, operations[].tool) and forwards each call to the editor over the existing bridge. One tool set whether the editor is embedded or opened directly; the SDK restates nothing the manifest publishes.

It also carries the SDK regeneration against the current manifest (16 operations) and the lifecycle events derived from it.

Changes

• createEmbed({ webMCP }) and <EmbedPDF webMCP={...} />: { enabled: true } registers every operation, { enabled: true, exclude: ['submit', ...] } withholds some by SDK method name, { enabled: false } and omitting the option are one state; a malformed value, an unknown key or a misspelled name throws EmbedConfigError at construction
• Each tool is the manifest record verbatim: the simplepdf_embed_* name, description, snake_case input schema and behavior hints (readOnlyHint + untrustedContentHint on the readers, destructiveHint on the rest, openWorldHint where the editor fetches an agent-supplied URL); all 16 operations register, loadDocument included, like the editor's own registration
• A tool call resolves with an MCP tool result carrying the editor's wire-shaped { success, data | error } Result (isError on failure); simplepdf_embed_get_annotated_page carries its PNG as an image content block, the badges map in the text block; the envelope is chosen per operation in an exhaustive switch, so a new operation has to declare text or image; a call whose signal is already aborted rejects and never reaches the editor
• Registration waits for the editor to leave booting, re-probes for a model context on later transitions, and lazy-loads the WebMCP module only then; tool names are page-level (the first embed owns a name, a second one is warned); dispose() unregisters everything
• getAnnotatedPage({ page }) joins IframeActions, useEmbed().actions and the tool subpaths; the generator honors the badges map shape (additionalProperties as Record<string, T> / z.record)
• EDITOR_READY and DOCUMENT_LOADED come from the manifest events like PAGE_FOCUSED and SUBMISSION_SENT; internal-protocol.ts is gone and the EditorEvent union is drift-guarded for exact equality with the generated outbound events
• The WebMCP docs state the data path as it is: every operation runs in the browser and nothing the agent reads is computed server-side; document storage follows the account's configuration exactly as without WebMCP (SimplePDF-managed, S3, Azure Blob Storage or SharePoint); loadDocument is named in the recommended exclude
• Tests for the bridge path (registration set incl. loadDocument, exclude by method name, wire round trip in snake_case, image block and its fallback, an aborted call, readiness gate, dispose, name ownership, no-context and invalid-context diagnostics), the option validator (every malformed shape, an unknown key, an unknown name) and the React prop (registers, unregisters on unmount, the remount key's equivalence pairs); READMEs, three changesets (minor for both packages), API reports, bundle budgets

Notes

• The WebMCP specification JSON-serializes whatever execute resolves with and defines no image channel; the image block pays off on runtimes that map results onto MCP's CallToolResult, and the plain-JSON path sees the same bytes either way (the PNG travels once).
• Deliberately not done here: registering only the operations the account configuration allows (needs an EDITOR_READY payload change on the editor side); a client-side cap on in-flight tool calls (a same-page script has the same power today); the root README's data-path sentences (healthcare and Copilot sections), revisited in a follow-up.
• Release lane: both packages ship as minor. The OutboundEventType widening (two members) is stated in its changeset.

Review outcomes